Cloud computing provides computation capacity and storage on demand. Typical cloud computing service agreements are based on a self-service usage model which allows a virtually unlimited amount of computing resources to be dynamically requisitioned, on demand, from a pool of shared computing resources offered by a cloud computing vendor. In a typical cloud-provisioning sequence, a user requests a virtual server from a cloud computing vendor through the vendor's user interface (through a web application, for example) and the server may be available within a few short minutes. This eliminates the need to buy a significant portion of the capital equipment upfront. Moreover, provisioned cloud computing resources are programmable. For instance, when an application needs additional capacity due to unexpected or peak consumer demand, the capacity may be dynamically and immediately requisitioned through a simple Application Programming Interface (API) call. There is no longer the need to over-provision to accommodate peak demand.
Cloud computing may include many different types of cloud services. One sample service is Infrastructure as a Service (IaaS), where a user can request Virtual Machines (VM). Other services may include key value storage services, semi-structured storage services, or messaging services. Although the cloud computing model gives individuals quicker access to the resources, it also presents significant problems for enterprise management. These problems include, for example, a lack of control over resource usage, and difficulties in data sharing with other group or team members, even with access to the same cloud computing resources. First, the conventional purchasing model employed by many cloud computing vendors does not conform to the standard enterprise purchasing order process, which can result in additional complexities in budget allocations. According to a common cloud computing practice, individual developers employed by an enterprise may still requisition cloud resources separately during the course of employment. Under such practices, the developer may be billed by the cloud computing vendor personally, and may be subsequently reimbursed by the developer's employer. Unfortunately, in these situations enterprise managers may not have control or even direct knowledge over the individual developer's resource usage until that usage is billed. Since developers may accrue cloud computing service charges personally, a manager may have little to no control on keeping usages within or under budget. Typically, managers and executives may see a total accrued cost only at the end of the month when the developer submits for reimbursement.
Potentially of even greater concern, an IT department may have little to no control over the data an individual may store in a cloud resource and may be unable to enforce corporate policy. Since a cloud account is under the absolute control of the individual user (and not, generally speaking, the department or supervisor's), a disreputable employee could easily abuse the system. For example, a security policy may mandate that all data stored in a cloud should be encrypted, but an individual can easily ignore the policy, knowing that the IT department or supervisor has no ability to audit. The developer may also store company sensitive data in cloud resources against company policy, for example, and sensitive corporate (proprietary) data may be subject to potential exploitation without the corporation's awareness or knowledge if stored in a personal cloud account. Worse yet, when the employee leaves the company, there may be no easy way to recover company data stored in the developer's cloud account, or prevent the individual's removal, destruction, tampering or duplication of the potentially sensitive and valuable data.
Also, since each developer has (initially) exclusive access to any requisitioned cloud resources, sharing data stored in cloud resources with collaborating coworkers may be difficult. Currently, sharing data hosted in a cloud requires the proprietor of the cloud resource to be shared to acquire identification information within the system for each intended collaborating developer, such as an account ID, and assign data permissions to those IDs specifically. Unfortunately, individual account IDs may be hard to keep track as often the account IDs do not correspond (intuitively) to a user's actual name. Furthermore, data sharing is often with a group of people, so managing data sharing at an individual user level is often cumbersome and time consuming when larger numbers of collaborators are desired.
Moreover, cloud access is different from other resources access in that it typically requires two sets of credentials. The first credential, referred here as the master credential and typically implemented in the form of a user name and password combination, is used by an individual to gain access to the cloud portal. Master credentials are often configurable by the corresponding user. Once logged in to the cloud portal, the user can request the second credential, referred here as the cloud credential, which is typically in the form of a set of keys (e.g., access key and secret key) or authorization tokens. For the sake of security, the keys are typically fairly long and complex, often appearing as a randomized string of numbers, letters and symbols that do not conform to typical mnemonic structures, thus, sharing the keys may be cumbersome if many contributors are expected or desired.
Finally, usage of cloud computing resources often makes it difficult to manage credentials securely. Many cloud services are invoked through a web services API. A user must present valid credentials in order to successfully invoke these APIs. The ability to share certain provisioned cloud resources between multiple users may also compromise credential security. For example, a requisitioned cloud virtual machine (VM) image may be shared between users. If a VM image needs to access other cloud services and/or services however, the VM image may have to embed the cloud credential in order to successfully proceed through embedded security protocols. Unfortunately, when the VM image is shared with other users, the user's cloud credential may inadvertently be shared amongst the other users as well.
Even if a VM image is never shared, since the image is stored in the cloud, there is the danger that a hacker may hack the image file to obtain the credential. In addition, when the credential is changed (rotating credential regularly is an increasingly popular cloud practice), the shared VM image must be changed. Unfortunately, data sharing in a cloud environment itself may be difficult. When a user needs to share data (e.g., either cloud-stored data or a VM image) with other users, the user must obtain the other users' cloud account IDs and then share the data with the targeted IDs. Since the mapping from a user to the user's cloud account ID is often maintained manually, it is cumbersome and time consuming to manage data sharing.